Many different portable devices can communicate with a gateway device. The gateway acts as a bridge between the wireless portable devices and the wired computer networks, such as the Internet or other wireless networks. A gateway device may include a standard server, with additional software that allows communications to be made between the gateway and the portable devices, which may be wireless, and between the gateway and other devices that desire information from the wireless devices, and with which the gateway may be in communication.
Developers may write custom application software for the portable devices. However, such software may only serve to identify values of interest with the values remaining on the portable devices. Getting the values from the device to the gateway, and from the gateway to other devices that can use such values can involve significant effort. To perform such functions, a communication facility must be written for the device. A separate facility must also be written for the gateway to allow it to receive and store the values. However, it may be desirable to make the communication facility operate as efficiently as possible, and thus using conventional communication facilities may not achieve the desired level of communication efficiency. Furthermore, the use of a conventional facility to communicate the values of interest from the devices to the gateway would require the programmer to convert the values into a format used by the communication facility. The applications programmer may not have the expertise to make the most efficient communications, and acquiring such expertise would be a time consuming task. Even then, some efficiency may be lost.
The communication facility between the device and the gateway is not the only modification that would be required in such a system. It would also be necessary to provide a facility to allow the gateway to receive and respond to requests from external sources for the values received from the devices in an easy to use format. Conventional Web services provide such a format, but there are several of these formats, and it can be tedious to write conversion software for the gateway that will accept requests in any of several Web services formats and return the proper response to the originator of the request. Not only is the software to perform all of these functions tedious to write, but it can also require knowledge of communications techniques and Web services formats that the developer of the application software for the device may not wish to learn.
Furthermore, different types of devices and different gateways may each use their own data formats, making the conversion of any format on the devices to any format on the gateways, in order to allow any device to communicate with any gateway, an unwieldy problem.
The developer may have put a great deal of thought into the data structures that are used to provide the data, and the developer may wish to use those same data structures or something very similar when data is provided in response to a query. Thus, it is desirable to maintain, as closely as possible, the data structures used on the device when the data is made available on the gateway.
To enable the developer to maintain the same data structures, the developer may program the gateway to respond to requests for values received from devices. However, the owner of the gateway may be different from the developer of the device, and the owner of the gateway may wish to employ a uniform standard of operation. The owner of the gateway may thus be reluctant to allow each developer of an application on the device to program the gateway, because each developer of a multitude of applications could introduce slight changes in convention that would make it difficult for parties that use the gateway to do so in a consistent fashion when information that was programmed by different developers is retrieved. Thus, it may not be desirable to have the developer of the device develop applications on different gateways.
If different parties develop for the device and the gateway, compatibility testing becomes more complex. The significant compatibility issues repeat themselves via the interface to the gateway from the other devices requesting the information stored on the gateway. Parties who desire to use the gateway to request information from a device must know the format into which the request must be made, and must know how the response will be received. Frequently, a programmer programs the gateway software, and a technical writer writes the instructions for the parties who will use the gateway. This can be not only a source of compatibility problems between the documentation and the software, but the technical writer is so far removed from the programmer of the device, that nuances in the data structures can be completely missed.
The compatibility testing between these three areas is not only time consuming and tedious to perform, but the errors that inevitably slip through can again cause the system to operate improperly, and problems can be difficult to identify. The significant compatibility testing between these three areas is thus a major source of frustration and expense.
It can be desirable for any solution to use a flexible approach to allow for differences in the various gateways that may be used to communicate with the devices. Different gateways may use different compiler software and their operators may desire to use different types of web services or other similar approaches to provide the interface with the senders of the requests for data from the devices. Thus, allowing sufficient flexibility to choose the type of interface, and type of compiler can be helpful.
Because the devices may be mobile, they may move in and out of range of different gateways at different times. There may be dozens or hundreds of such devices, and each device may support a variety of applications. Requiring every gateway to have interface software for every possible device can be a logistical nightmare. It would be desirable if the gateway software for every possible device did not have to be installed on every gateway. It would also be helpful if the device software and gateway software could handle communication interruptions as the device moved in and out of range. However, because storage space on a device may be at a premium, it is desirable to handle such interruptions in communication in a flexible manner.
What is needed is a system and method that can allow information to be obtained from a device using a gateway that does not require a programmer of a device or gateway to write a communication facility between the device and the gateway and from the gateway to the requesters of information provided from the device to the gateway, reduces or eliminates compatibility testing between the gateway and the device, allows the programmer input into the description that allows parties using the gateway to request information from it, is compatible with a variety of capabilities of the gateways that may wish to provide information from devices, can handle interruptions, and does not require the gateway to have installed all of the interface software for every possible device until such software is used.